1. Field of the Invention
The present invention relates to a process for optimizing accesses to a database.
2. Description of Related Art
Information Management Services for access to the information of an MIB (Management Information Base) are based on the CMIS standard (Common Management Information Service, ITU-T recommendation T X.710), which describes the operations that can be performed on specified objects in accordance with the model of the GDMO standard (Guidelines for the Definition of Managed Objects, ITU-T recommendation X.722).
The present invention uses the information management service in the CMIS standard. This service is attached to the CDSP (CMIS Dispatcher Process) (FIG. 4, 42), which is a service for exchanging CMIS packets between entities of the OpenMaster(trademark) platform. Which is an enterprise management software suite of BULL S.A., a French company, having offices at Louveciennes, France. OpenMaster(trademark) is a total enterprise-wide solution involving security, asset management, application deployment and system and network operations, all linked by an underlying, integrated, open and flexible architecture. Further information regarding OpenMaster(trademark) software suite can be obtained at http://www.openmaster.com. CDSP is a packet router for the management information service, i.e., a system for transferring data between two entities using the same protocol. The management applications call either agents (43a, 43b, 43c) or local services of the platform that make it possible to locally manage a Management Information Base (MIB) organized hierarchically in the form of an object tree, without network access. In these management information bases (MIB), all the resources are represented in the form of objects in an object tree, as represented in FIG. 2.
The objects themselves are grouped into classes. An object of a given class has a certain number of attributes, and each object instance has a distinguished name (DN). Addressing is done by means of a distinguished name (DN). For example, the DN of the object (51, FIG. 2) is xe2x80x9ca/a/bxe2x80x9d.
FIG. 4 represents the operation of an information management service. This service uses a two-level architecture. The first level is constituted by a manager entity (4) playing the role of a manager that must display and monitor resources, look up characteristics, etc. The second level is constituted by remote or local agent entities (43a through 43c), which maintain the objects to which the operations sent by the manager level are to be applied. The purpose of an agent is to maintain a model of the resource it manages, a standardized model journaled in an MIB. At least one agent is installed in each machine of the network and can control a set of local or remote resources under the direction of one or more managers. A manager communicates with each agent using a standard management protocol. The OpenMaster(trademark) management system marketed by the French company BULL, S.A. comprises one or more managers called ISM (Integrated System Management) and a plurality of agents (ISM Agent). Moreover, other agents marketed by other companies can be controlled by the OpenMaster(trademark) manager via standard protocols.
The manager-agent mechanism is based on an object model in which the modeling of a resource constituted, for example, by elements of the system, software, states, users, etc., is based on an object-oriented approach and structuring of the management information. The xe2x80x9crealxe2x80x9d equipment of a networked system (a computer, a printer, a circuit, etc.) is represented by abstract objects organized into a management information base (MIB). The characteristics of these objects (the name of a computer, the characteristics of the peripheral equipment, the status of this equipment such as a printer, etc.) are called the attributes of the objects.
The objects are divided into what are most often called MOCs (Managed Object Classes), in which each MOC represents a type of resource. The MOCs define the information that the MIB will contain for each type of resource, i.e., what attributes the object will have. The MOCs can be interpreted as being part of the xe2x80x9cschemaxe2x80x9d of the MIB. The manager records an object class MOC in the GDMO language, and it declares, among other things, the classes, and for each class, a list of attributes, name bindings, etc. This description is recorded in a GDMO object definition module attached to the manager ISM (41). Each MOC is instantiated in several MOIs (Managed Object Instances) representing the actual occurrences of this type of resource.
Take the example of three printers (Print1, Print2, Print3) represented by three object instances (P1, P2, P3) in a management information base (MIB). The attributes of the object representing the printer are xe2x80x9cprinter statusxe2x80x9d and xe2x80x9cuserxe2x80x9d. It is therefore possible to define an object class MOC xe2x80x9cprintersxe2x80x9d having xe2x80x9cprinter statusxe2x80x9d and xe2x80x9cuserxe2x80x9d as its attributes. The object instances (MOIs) of the class xe2x80x9cprintersxe2x80x9d can be the following:
The status of the resource Print activated without the current user in the instantiation of the above example. This example also includes the instances Print 2 and Print 3. An application such as xe2x80x9cISM Monitorxe2x80x9d supplied by the OpenMaster(trademark) management system (4) makes it possible to display the MOIs and their statuses. Likewise, ISM Monitor (46) can display, in table form, the attributes of any MOI, for example the attributes xe2x80x9cprinter statusxe2x80x9d and xe2x80x9ccurrent userxe2x80x9d for any MOI of the MOC xe2x80x9cPrintersxe2x80x9d.
The entire set of managed objects forms a management information base (MIB).
A sub-tree directly attached to the root of the distinct tree of a management information base (MIB) is called an xe2x80x9cMIBletxe2x80x9d. In spite of the division into MIBlets, the management information base (MIB) of the OpenMaster(trademark) management system is recognized as a single composite entity, with all the MIBlets attached to the same MIB. An object MOI at the root of a MIBlet is called a xe2x80x9cRootletxe2x80x9d. The OpenMaster(trademark) manager views the distributed system through the objects of the MIB and the system is controlled by manipulating objects of the MIB and their attributes. The objects are visible via the agents or the object manager attached to the OpenMaster(trademark) manager, which map the equipment in an MIB in the form of an object tree. An agent can represent the status of a piece of equipment via a corresponding associated object represented in the MIB. This mapping can associate an object with several xe2x80x9crealxe2x80x9d pieces of equipment; likewise, a piece of equipment can be modeled in the form of several objects. The OpenMaster(trademark) manager (4) sends commands to the agents (43a through 43c) and the agents (43a through 43c) send responses to its commands and notify the OpenMaster(trademark) manager (4) of events through integrating agents (45a), using a protocol such as SNMP (Simple Network Management Protocol, 45a), CMIP (Common Management Information Protocol, 45b), or others such as DSAC/AEP (Distributed Systems Administration and Control/Administrative Exchange Protocol) (45c). Each management protocol provides a certain number of simple operations; for example, the protocol CMIP provides all the functions of the CMIS standard, i.e., the following:
the manager (41) can read the attributes of an MIB object (the operation M-GET). The agent (43) responds to a query M-GET by providing information on the equipment;
the manager (41) can modify the attributes of an MIB object (the operation (M-SET). The agent (43) modifies the xe2x80x9crealxe2x80x9d equipment as a function of the new attribute values provided by the manager;
the manager (41) can create and delete objects of the MIB (the operations M-CREATE and M-DELETE);
the manager (41) can perform an action on an MIB object (the operation M-ACTION). The agent (43) performs an action on the equipment as a function of the action requested by the manager on the abstract object;
the agent (43) can notify the manager of an event taking place in an object of the MIB (the operation M-EVENT). The agent sends information on an event involving an abstract object in order to describe an event that took place in a xe2x80x9crealxe2x80x9d piece of equipment.
A management information base (MIB) has a strict tree structure hierarchy, which means that each object instance (MOI) has one and only one superior MOI. The tree formed by the management information base is called a xe2x80x9ccontainment tree.xe2x80x9d The managed object instances (MOIs) are named by their position in the containment tree in the following way:
Each MOI has a relative distinguished name (RDN) which differentiates the MOIs having one and the same superior (father) MOI. One of the attributes of each managed object class (MOC) is chosen to specify the RDN of the instance for a given superior MOI. This attribute, called the naming attribute, is identified in the GDMO templates known as name bindings. An MOC can have several potential superior name bindings, but each MOI uses only one of them. Each MOI also has a full distinguished name (Full Distinguished Name) that is unique in the MIB. The global distinguished name (DN) of an object consists of its relative distinguished name (RDN) joined with the distinguished name (DN) of its superior, which means that the distinguished name (DN) of a managed object instance (MOI) contains its own relative distinguished name (RDN), plus the relative distinguished names (RDNs) of all its superiors in the containment tree up to the root.
The management information base (MIB) makes it possible to establish relationships between objects other than the relationships established in the containment tree by distinguished names. These relationships are established using relationship attributes. These attributes contain the global distinguished names (DN) of other objects. They are used as references from one object to another.
One of the local object managers of the manager ISM-Manager is called CMIS-DB. It is responsible for storing part of the local MIB. The remanence of these stored objects is ensured by ISAM (Index Sequential Access Method) files. This ISAM technology, which describes the structures of records, is a method for accessing files structured in the form of records divided into one or more indexes and data.
When the application of the manager wishes to select one of the objects in order to perform a CMIS operation, for example an M-GET, it must specify the base object instance (BOI), the scope and the xe2x80x9cfilterxe2x80x9d as arguments of the operation.
The base object instance (BOI) makes it possible to identify an object in a management information base (MIB), which is the starting point for an evaluation of the scope-filter pair in the object tree. The scope selects a portion of the tree from this base object. For example, the scope xe2x80x9cWhole sub-treexe2x80x9d makes it possible to select all the sub-trees of a given object. Among all the objects in the scope, the objects selected are those for which the evaluation of the filter is true. The operation is performed on the objects actually selected. The manager sends an M-GET on the objects and CMIS-DB reads and returns to the application the value of the attributes of the objects selected.
In order to reach a base object instance (BOI), the manager CMIS-DB must go from father object to son object until it reaches the node of the base object. This navigation operation can be lengthy if, in order to go from one node to another, it is necessary to physically read all the sons of a node and choose from among them the one that has the right RDN, and so on. Once the computer has reached the base object instance, it must read the attributes of the objects of the base that correspond to the scope in order to be able to evaluate the filter in storage. The generic condition for storing objects imposed by the old version of CMIS-DB is to physically read all the selected objects belonging to the scope before evaluating the filter in storage. When there are a lot of objects subordinate to an object, performance can be quite poor. In order to understand the problem, it is important to remember that the generic storage in the previous versions of CMIS-DB made it possible to manage objects in the base without requiring a pre-declaration of their format in the server. This is an advantage over other systems, which first require compiling the description of the objects in the object base in order to be able to process them, and therefore does not make it possible to create an instance of the class of the objects if this class has not been described. CMIS-DB, on the other hand, performs this operation automatically, but the generic storage of the objects of the MIB by default results in the performance problems described above. CMIS-DB uses data structures that make it possible to generically create instances of any object class of the MIB on the physical disk of the system, without having prior knowledge of the description in accordance with GDMO.
In the generic representation of CMIS-DB, knowledge of the structure of the objects is obtained during the CMIS operations M-CREATE for creating instances, sent by the client applications to the server CMIS-DB.
It is the applications that correctly format the M-CREATE operations by using online the GDMO descriptions recorded in the OpenMaster(trademark) module, which compiles and stores the GDMO definitions of the objects managed by the manager ISM.
One object of the present invention is to offer a process for optimizing accesses to a database organized into trees, particularly for a management server managing a very large management information base (MIB), making it possible to perform complex operations on a very large number of objects while reducing the search times for the instances selected by the scope and filter arguments of CMIS operations.
This object is achieved by the fact that the process for optimizing accesses to a database is characterized in that it allows the client applications to request the CMIS-DB server, via an online configuration, to customize the generic representation for the object classes for which the access times must be optimized in order to reduce the search times for the object instances selected, by performing a step for configuring the physical storage of an object class to be optimized, which consists in the creation of an object instance of the storage definition class (mocStorageDefinition) in which are declared the attribute or attributes of the class to be optimized, which will be indexed when physically stored on a disk.
According to another characteristic, the process comprises a second step consisting of writing one ISAM (Index Sequential Access Method) file per managed object class (MOC) optimized, a specific file with its own index structure containing the representation of all the instances of this MOC.
According to another characteristic, the process comprises a third step consisting of analyzing the filters conveyed by the CMIS operations sent by the users in order to identify, in a pre-filtering step, whether or not the evaluation of this filter can be performed using one of the indexes set in the base.
According to another characteristic, the value of the physical indexes for indexing the attributes specified in the object instance of the class mocStorageDefinition corresponding to the MOC to be optimized includes the unique 4-byte long reference of the node of the father instance (fatherMOInodeRef) of the managed object instance and the sequence of the attributes 1 through i necessary to the managed object class to be optimized.
According to another characteristic, when a pre-filtering by the attributes indexed in the underlying database can be used, the query performer in the management information base (MIB query performer) determines the arguments of the physical read operation, making it possible to reread in the underlying base only the subordinates that are indexed by the values of the attributes selected for the pre-filtering.
According to another characteristic, the managed object class (mocStorageDefinition) makes it possible to specify a plurality of indexable attributes that will be physically stored in the index the moment the object is created.
According to another characteristic, the plurality of indexes described in the managed object class mocStorageDefinition can be reorganized at any time by assigning a different index level to one or more attributes or by activating or deactivating the indexes via the modification of the object of class mocStorageDefinition.
According to another characteristic, a query performing module of the information management service CMIS-DB, after detecting a possibility for pre-filtering through the knowledge of the mocStorageDefinition of each class optimized, performs the reading in the underlying database of only the objects of the scope that are indexed by the values of the attributes selected for the pre-filtering.
According to another characteristic, means are provided to allow the user to choose the most discriminating attribute or the attribute group by sorting the defined indexes in decreasing order.
According to another characteristic, the optimizer recognizes the filters than can result in a pre-filtering for the indexes; these are the filters constituted by an AND clause including:
an equality item in the attribute objectClass, a value equal to the identifier of one of the optimized MOCs,
a logical expression constituted only by AND clauses including comparison items in the attributes declared in the indexes of this optimized MOC.